@roomote-agent

Please review this pull request.

1. Does it complete the objectives of the issue?
2. It should not affect any functionality other than Java methods.

Hi @NaccOll! I've seen your review request and I'm now reviewing this PR. I'll check if it properly addresses issue #7330 and verify that it only affects Java method handling as requested. I'll provide detailed feedback shortly.

Pull Request Review Complete ✅

Hi @NaccOll! I have completed my review of this PR. Here are my findings:

1. Does it complete the objectives of issue #7330? ✅ YES

The PR successfully addresses both issues mentioned in #7330:

• Fixed: Java interface methods (even single-line ones) are now properly recognized instead of being filtered out
• Fixed: Java methods with @Override annotations now show the actual method name instead of just "@OverRide"

2. Does it only affect Java method handling? ✅ YES

The changes are properly scoped to Java-specific handling:

Key Changes:

1. Language-specific skip rules: Added LANGUAGE_SKIP_RULES configuration that currently only affects Java definition.method captures

2. Smart line detection for Java methods: New findJavaMethodSignatureLine() function that:

   • Skips annotations (like @Override, @Test) to find the actual method signature
   • Uses optimized regex patterns to avoid backtracking issues
   • Falls back gracefully if no signature is found

3. Conditional line count checking: The shouldSkipLineCountCheck() function ensures that Java methods are exempt from the 4-line minimum requirement while other languages remain unaffected

Code Quality Assessment:

Strengths:

• ✅ Clean, modular implementation with language-specific handling
• ✅ Extensible design - other languages can easily be added to LANGUAGE_SKIP_RULES
• ✅ Performance-conscious regex patterns that avoid catastrophic backtracking
• ✅ Comprehensive test coverage with 12 passing test cases
• ✅ All existing tests (304 tests across 60 test files) continue to pass

Minor Suggestions for Future Improvements:

• Consider adding a comment explaining why Java methods need special handling (OOP nature, interfaces, annotations)
• The regex patterns in findJavaMethodSignatureLine() could potentially be extracted as constants for better maintainability

Test Results:

✓ All Java-specific tests pass (12/12)
✓ All tree-sitter tests pass (304/304)
✓ No regression in other language parsers

Conclusion:

This PR effectively solves the reported issues without introducing any side effects. The implementation is clean, well-tested, and properly scoped to Java. The approach of using language-specific rules is a good architectural decision that will make it easy to handle similar issues in other languages if they arise.

Recommendation: APPROVE ✅

Great work on this fix! The solution elegantly handles the unique characteristics of Java code while maintaining backward compatibility.

Hey @NaccOll thank you for your contribution! Can this problem be solved by removing the minimum line check for all the languages? I would prefer a general fix rather than creating langauge-specific parsing functions.

Let me know what you think!

Hey @NaccOll thank you for your contribution! Can this problem be solved by removing the minimum line check for all the languages? I would prefer a general fix rather than creating langauge-specific parsing functions.

Let me know what you think!

There are two problem here.

1. For object-oriented languages, the listCodeDefinitionNamesTool always ignores their interface definitions due to the minimum line check.

Because interface definitions often only have method signatures and no implementation, they are only one line. This issue can be addressed with the following method:

if (["definition.method"].includes(capture.name)) {
return false
}

I only did this for Java because I wanted to focus on resolving the issue mentioned.

2. The first line of a method definition is not the method signature itself.

For Java, I modified the syntax capture expression to capture both annotations and method signatures.(by definition.method.start)

Please review again.

The PR description mentions that "The original design was to avoid returning small, meaningless blocks, but this doesn't fit with object-oriented design language." Since the core issue is that the 4-line minimum threshold filters out legitimate Java interface methods and single-line methods with annotations, wouldn't it be simpler to just reduce the DEFAULT_MIN_COMPONENT_LINES_VALUE from 4 to 1 or 2 globally?

First, changing DEFAULT_MIN_COMPONENT_LINES_VALUE to 1 only resolves signature retrieval for methods with only three lines. To address the issue of one-line methods in interface classes in object-oriented design languages, changing DEFAULT_MIN_COMPONENT_LINES_VALUE to 0 is necessary. However, changing DEFAULT_MIN_COMPONENT_LINES_VALUE to 0 results in returning small, meaningless blocks.

Please allow me to further explain a few key changes.

1. The reason for skipping line count checks only for definition.method and definition.method.start is to return the method signatures in the interface class while avoiding returning meaningless lines of other syntaxes, such as various imports and single-line comments.
2. The Java query was modified to retrieve the corresponding method signature when an annotation is present in the Java method.
3. The Java query change causes method signatures to be displayed twice when the Java method does not have an annotation. The deduplication logic is designed to address this issue. However, in a subsequent pull request, I will implement this deduplication logic for all syntaxes. I've discovered that each language has its own duplication issues.

The image directly is more intuitive.

Change DEFAULT_MIN_COMPONENT_LINES_VALUE to 1

You can see that changing it to 1 has no effect

Change DEFAULT_MIN_COMPONENT_LINES_VALUE to 0

You can see that after changing it to 0, the methods of the interface class can be obtained, but the methods with annotations in the implementation class still cannot be obtained, and many meaningless blocks are introduced.

If I change DEFAULT_MIN_COMPONENT_LINES_VALUE to 0 and then modify the Java query, I can get the annotated method signatures of the implementation class, but there are still a lot of meaningless blocks, and the non-annotated method signatures appear twice, even though this only requires changing two lines of code.

If you think the deduplication logic is too complex and meaningless, I can remove the third point in the key changes. However, it makes sense to modify the Java query and skip the row check only for the method. Please let me know what you think.